Videoconferencing systems are conventionally adjusted to employ both circuit switched and packet switched networks. Thus, great efforts have been made to achieve interoperability between circuit switched and packet switched terminals allowing interactions and communication without loss of quality or introduction of delay. A common standard for multimedia communications over circuit switched networks like ISDN is the H.320 standard from the International Telecommunications Union (ITU). The corresponding standard for packet switching is the H.323 standard.
As already mentioned, H.323 is an umbrella recommendation from the International Telecommunications Union (ITU) that set standards for multimedia communications over packet switched networks that do not provide a guaranteed Quality of Service. Such networks are pervasive on many corporate terminals and include TCP/IP and IPX over Ethernet, Fast Ethernet and Token Ring network technologies. The H.323 standard, titled: Packet-Based Multimedia Communications Systems, provides a foundation for audio, video, and data communications across IP-based networks, including the Internet. Multimedia products and applications complying with the H.323 standard are interoperable, can communicate with each other, and thus are compatible. Many sub standards make up the H.323 standard or protocol, one of which is the H.245 standard.
The H.245 standard defines the control protocol part of the H.323 standard. According to this protocol, there are several ways of altering the flow rate during a call. The most robust way is to send a flowControlCommand to the transmitting terminal. The flowControlCommand includes the fields logicalChannelNumber and maximumBitRate. The maximumBitRate indicates maximum allowed bit rate for the logical channel. The message is not rejectable, i.e. a terminal is not allowed to transmit at a higher rate after receiving the message. The flowControlCommand is i.a. used for initially setting a negotiated maximum data rate between terminals. An alternative way of altering the bit rate is to use the Logical Channel bit rate message flow. For illustrative purposes, consider a gateway using the Logical Channel bit rate messages to alter a flow rate transmitted from an EndPoint. A LogicalChannelRateRequest message is transmitted from the Gateway to the EndPoint. The message includes a logicalChannelNumber indicating the logical channel that the bit rate change request applies to, in addition to a maximumBitrate indicating, in units of 100 bit/s, the requested maximum bit rate for the logical channel. The Endpoint approves and acknowledges the request for data rate change of the specified channel by returning a LogicalChannelRateAcknowledge message including the same parameters as in the previously received LogicalChannelRateRequest message. Alternatively, if the EndPoint for some reason does not accept the requested change, the LogicalChannelRateRequest message is responded by a LogicalChannelRateReject including rejectReason indicating the reason why the request was denied.
An alternative protocol to H.323 is the SIP (Session Initiation Protocol) protocol. In the current SIP standard, altering the flow rate during a call is carried out by transmitting a ReInvite message to the EndPoint. The ReInvite message carries the same information as the Invite message, including a so-called CapSet, which is used at call set up. Thus, the ReInvite message also includes maximum allowed bit rate, and consequently, transmitting a ReInvite message with a new maximum allowed data rate leaving the other data unchanged will have the same effect as the flowControlCommand in H.323.
A gateway provides a connection between the IP and the circuit switched side of the communication path between endpoints in a multimedia conference. Seen from the endpoints residing at the IP side, the endpoints at the circuit switched side are virtually being converted to IP endpoints, and vice versa. The main tasks of the gateway is consequently to translate and re-pack the data stream across the networks in real-time. The packets transmitted from the H.323 endpoints are temporarily stored in a buffer before they are fetched and arranged in H.320 frames of a fixed size.
The translation process from H.323 to H.320 in the gateway is accomplished by extracting raw video data from packets specified by RFC2032 (H.261 over RTP), RFC2190 (H.263 over RTP) and RFC 2429(H.263+ over RTP) and forwarding this raw data to a so-called BCH encoder.
When translating in the opposite direction from H.320 to H.323 the process is a lot more complex because the packetization schemes described in the RFC's mentioned above have strict rules about where a packet split may occur. Specifically packet splits are allowed at Picture, Group Of Block (GOB) and Macro Block (MB) level. It is most desirable to have splits occur at the Picture and GOB levels because a split on the MB level has some associated overhead due to the need to transmit some video decoder state information along with the video data.
A conventional implementation uses variable length decoding to determine the location and length of Groups Of Blocks (GOB) in the video stream. When it has found a GOB, it processes the corresponding bits by using the number of bits in the GOB (a), the number of available bits in the current packet (b) and the maximum packet size (c), to choose one of the following actions:                If a<=b, append the GOB to the current packet        If a>b and a<=c Transmit the current packet and append the GOB to a new packet        If a>b and a>c Transmit the current packet and transmit the GOB using less optimal macroblock level packetization.        
These three rules optimize packetization to fit the entire GOB in a packet if possible while also combining several GOBs in one packet where possible. This is desirable because GOB aligned packets have less overhead and few large packets require less processing overhead than many small packets.
In addition to the above rules, packets are also transmitted when the last GOB in a picture is added to a packet. This additional rule prevents the gateway from accumulating unwanted delay.
H.323 endpoints and H.320 endpoints connected together in a gateway unit are not able to use end-to-end flow-control because the H.320 protocol does not support it. However, flow-control can be used between the gateway and the H.323 endpoint. Only the flow-control messages from the gateway to the H.323 endpoint will have any effect. A typical scenario e.g. in known H320/H323 Gateways from Polycom and Ezenia is that the gateway initially will send flow-control messages to the H.323 endpoint to adjust the video data rate produced to the available capacity in the outgoing H.320 connection from the gateway. It is not possible to flow control the H.320 endpoint because the H.320 protocol simply does not support this. This means that the H.320 could produce more video than the H.323 endpoint supports. Only the flow-control messages from the gateway to the H.323 endpoint will have any effect. The effect will depend on flow-control support in the H.323 endpoint.
A problem then occurs when the H.323 endpoint for some reason starts to transmit data to the gateway at a higher bit rate than initiated by the flow-control. This may occur because of defects in the endpoint, loss of data settings or a drifting or incorrect wall clock. The gateway will then not be able to capture data to H.320 frames as fast as the buffer is filled up. In the first instance, this implies increasingly larger delays in the data transmission because the payload will spend longer time in the buffer, which will be crucial to real-time applications like videoconferencing. Additionally, at some point, the upper fill limit of the buffer will be reached. When the upper fill limit is reached, the gateway has no other choice than to reject subsequent incoming data. The result of this is loss of data appearing for the user of the H.320 endpoint as i.a. picture artifacts.